---
title: "【翻译】Sysctl调节Linux网络性能"
categories:
- linux
- tcp
tags:
---

<div id="content">
<div id="table-of-contents">
<h2>Table of Contents</h2>
<div id="text-table-of-contents">
<ul>
<li><a href="#orgd60c2b2">Intro</a></li>
<li><a href="#org8d95f23">Round Trip Time 往返时间</a></li>
<li><a href="#orge5719a8">TCP和其连接类型</a></li>
<li><a href="#org56af572">segments, packets, and frames</a>
<ul>
<li><a href="#orgfd0ed04">Flow Control in TCP</a></li>
<li><a href="#orgc34dae0">Bandwidth Delay Product</a></li>
</ul>
</li>
<li><a href="#orgcf2a739">原文，防链接失效</a></li>
</ul>
</div>
</div>
<div class="outline-2" id="outline-container-orgd60c2b2">
<h2 id="orgd60c2b2">Intro</h2>
<div class="outline-text-2" id="text-orgd60c2b2">
<p>
使用sysctl调整Linux网络性能
</p>
<p>
<a href="https://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl">https://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl</a>
</p>
<p>
Linux kernel version 1.3.57之前的版本，如果想要调整内核参数，必须重新编译内核…
</p>
<p>
多亏了sysctl的引入，我们现在能在运行时调整内核参数。在此以前，几乎所有的内核参数都是写成常量的。我们首先看看sysctl能够修改的东东：
</p>
<ul class="org-ul">
<li>Device parameters 设备参数</li>
<li>Network parameters 网络参数</li>
<li>Firewall behavior 防火墙行为</li>
<li>File system 文件系统</li>
<li>NFS 极品飞车「手动滑稽</li>
<li>Processes 进程</li>
<li>Version details and much more.. 版本信息，还有更多。完整的列表通过如下命令查看：</li>
</ul>
<div class="org-src-container">
<pre class="src src-sh">[root@www kernel]# sysctl -a
</pre>
</div>
<p>
这里讨论sysctl如何修改网络参数。首先我们从基本的网络知识的TCP开始。
</p>
</div>
</div>
<div class="outline-2" id="outline-container-org8d95f23">
<h2 id="org8d95f23">Round Trip Time 往返时间</h2>
<div class="outline-text-2" id="text-org8d95f23">
<p>
指的是Sender发送数据到Receiver接收所用的时间，和从Receiver收到确认的时间。
也就是Sender发送一个IP Packet，到Receiver返回确认这断时间。
我们常用PING命令来测试。
</p>
<div class="org-src-container">
<pre class="src src-sh">C:\Users\sarath&gt;ping slashroot.in
Pinging slashroot.in [212.71.233.103] with 32 bytes of data:
Reply from 212.71.233.103: <span style="font-weight: bold; font-style: italic;">bytes</span>=32 <span style="font-weight: bold; font-style: italic;">time</span>=130ms <span style="font-weight: bold; font-style: italic;">TTL</span>=51
Reply from 212.71.233.103: <span style="font-weight: bold; font-style: italic;">bytes</span>=32 <span style="font-weight: bold; font-style: italic;">time</span>=130ms <span style="font-weight: bold; font-style: italic;">TTL</span>=51
</pre>
</div>
<p>
130毫秒就是请求slashroot.in的往返时间。作者的服务器在伦敦的某数据中心，作者从Hyderabad（印度）访问的来回时间是130毫秒。
</p>
</div>
</div>
<div class="outline-2" id="outline-container-orge5719a8">
<h2 id="orge5719a8">TCP和其连接类型</h2>
<div class="outline-text-2" id="text-orge5719a8">
<p>
TCP是面向连接的协议。何谓面向连接？因为在Sender和Receiver之间有任何数据传输之前，有一个reliable的建立连接的过程。
建立连接的过程是非常重要的，因为Sender需要正确地发送数据到Receiver，还要确认数据已经正确传送到了。
</p>
<p>
<a href="http://www.slashroot.in/understanding-tcp-three-way-handshake">http://www.slashroot.in/understanding-tcp-three-way-handshake</a>
</p>
<p>
连接一旦建立，数据就能双向地发送：Sender-&gt;Receiver, Receiver-&gt;Sender。发送的一方仍然要等待另一方的确认，以此确保数据正确的送到了。
</p>
<p>
注意：谁发送数据与是谁建立的连接无关。
</p>
</div>
</div>
<div class="outline-2" id="outline-container-org56af572">
<h2 id="org56af572">segments, packets, and frames</h2>
<div class="outline-text-2" id="text-org56af572">
<p>
人们常常误用了这几个词。其实它们是完全不同的。5层网络：
</p>
<ul class="org-ul">
<li>Application layer,</li>
<li>Transport layer,</li>
<li>Network Layer,</li>
<li>Data Link Layer,</li>
<li>Physical layer, the finally is the layer where data flows through the wire)</li>
</ul>
<p>
任何程序发送数据到远端服务器，例如，当你浏览这个页面的时候，操作系统和浏览器负责Application layer，
操作系统上的TCP套件负责Transport layer,
Network layer上是IP地址相关的，由操作系统上安装的networking stack负责，
Data link layer上是涉及到硬件的，例如MAC地址等，
Pysical layer封装最终要在线路上传送的数据。
任何发送到远程服务器的数据都会经过这些层，每一层都会在上一层的数据之上加上一点自己的信息。
</p>
<ul class="org-ul">
<li>Transport Layer 层上的数据叫作 Segments</li>
<li>Network Layer 层上的数据叫作 Packets</li>
<li>最后一层上的数据叫作Frames(即将在线路上传送的数据)</li>
</ul>
<p>
之所以说TCP是reliable是因为无论你发送什么，接收方必须回复确认收到————所有你发送的字节都必须被接收方确认。发送方还会重发对方没有确认的字节。
</p>
<p>
虽然我们说得很简单的样子，但是要实现这个reliable是一件相当棘手的任务，你需要考虑很多事情。
所幸，这些问题被Flow Control接手了。
</p>
</div>
<div class="outline-3" id="outline-container-orgfd0ed04">
<h3 id="orgfd0ed04">Flow Control in TCP</h3>
<div class="outline-text-3" id="text-orgfd0ed04">
<p>
Flow Control要解决的问题就是确定正确的发送和接收数量。Sender发送的数据不能大得把Receiver淹没了。
</p>
<p>
现在，这种控制是非常重要的，因为我们与不同的端连接的速度是不一样的。
</p>
<p>
TCP使用称作Sliding window Protocol的协议管理Flow Control。很简单：Receiver和Sender方都会告知对方自己能接受的数据量。
那么问题来了，这个量如何让对方知道呢？
这就是每个接收的送出的TCP Segment中被称作receive window的字段了。（请注意是TCP Segment，在Transport layer）。Receiver会告知自己能接收的数据量。
</p>
<p>
Sender在看到了这个window size之后，就不能再发送超出这个量的数据了，一直到收到确认。Sender再次收到的确认中又包含了一个新的window size，然后Sender又发送小于这个window size的数据。如此反复。
</p>
<p>
如果Receiver回复中的window size为0，Sender就不能发送任何数据了，直到Sender发送的上一份数据和确认函到达，Sender再根据其中的window size发送新的数据。
</p>
<p>
在Receiver发送新的window size之前，Sender不能发送任何数据。
</p>
<p>
每一份TCP Segemnt或者IP Packet中所能包含的数据都有一个限制，这个限制定义在TCP协议标准中。TCP并不是一种新的技术，它出身于网络还很慢的年代，当时的网络不像今天这样高速。
</p>
<p>
如今，出于性能的考虑，我们有必要做一些修改。<a href="http://tools.ietf.org/html/rfc1323">http://tools.ietf.org/html/rfc1323</a> RFS1323包含了有关TCP性能提升的详情。
</p>
<p>
限制：每个TCP Frame中所能包含的最大window size为65,535字节，这个值对于如今的网速来说太小了。
</p>
<p>
新的修订，带来了一个称作window scaling的东东，它能够使window size增加到1,073,725,440字节（大约1GB）。为了了解这个，让我们来深入一种称作 Bandwidth Delay Product的计算。
</p>
</div>
</div>
<div class="outline-3" id="outline-container-orgc34dae0">
<h3 id="orgc34dae0">Bandwidth Delay Product</h3>
<div class="outline-text-3" id="text-orgc34dae0">
<p>
带宽廷迟乘积？？
</p>
<p>
delay就是发送数据到收到回复产生的延迟，也就是Round Trip Time。
</p>
<p>
假设我们是10Mbps的带宽，RTT(Round Trip Time)为200ms，那么
</p>
<p>
Bandwidth Delay Product = 2 x 106  b/s x 200 x 10-3 s =  244.14Kilobytes
</p>
<p>
<a href="http://www.speedguide.net/bdp.php">http://www.speedguide.net/bdp.php</a>
</p>
<p>
上面这个链接能够计算Badnwith Delay Product
</p>
<p>
这个乘积的结果显示了要有效利用网络而需要传输的数据量。然而由于我们的操作系统65535字节window size的限制，导致连接没有充分利用。
</p>
<p>
因此TTS越大，要有效利用带宽所需要发送的数据就越多。（因为当延迟越在，为了有效利用带宽，每次发送的数据就越多）。延迟越高，这个乘积就越大。
</p>
<p>
为了解决这个问题，RFC 1323中的修订为我们带来了名为 TCP Window Scaling的东西。
</p>
<p>
{% raw %} Using Window Scaling option in TCP will improve your network throughput and speed, if you have your Bandwidth Delay Product more than 65kilobytes. {% endraw %}
</p>
<p>
现在我们开始修改Linxu系统TCP参数，通过sysctl.conf文件开启window scaling。
</p>
<div class="org-src-container">
<pre class="src src-conf"><span style="font-weight: bold; font-style: italic;">net.ipv4.tcp_window_scaling</span> = 1
</pre>
</div>
<p>
即使开启了window scaling，Sender无须获得确认，能发送的数据量的最大值，还有另外一个因素————receive window size，receiver接收缓冲区的最大值。
所以，即使Sender开启了window scaling，但是receiver的接收缓冲区只能容得下那么点数据，Sender仍然不能一次发送过多的数据。
配置receiver接收缓冲区，也是在sysctl.conf
</p>
<div class="org-src-container">
<pre class="src src-conf"><span style="font-weight: bold; font-style: italic;">net.core.rmem_max</span> = 16777216
</pre>
</div>
<p>
除了receive window size，Sender也要配置一个更高的最大send window size。
你估计在想为什么receiver和send的值是相等的。因为Sender必须跟踪它发送的数据，直到收到确认。如果没有收到确认，Sender必须重发所有的字节。（如果这些字节在缓冲中，Sender就能重发它，如果没有收到确认，缓冲中的数据就不会被flush）。
</p>
<p>
与修改max receive window size相似，以下是修改maximum send window size
</p>
<div class="org-src-container">
<pre class="src src-conf"><span style="font-weight: bold; font-style: italic;">net.core.wmem_max</span> = 16777216
</pre>
</div>
<p>
除了上面几个配置，还有几个是操作系统使用的，为不同的情况设置这些值的。也在sysctl.conf文件中。
</p>
<div class="org-src-container">
<pre class="src src-conf"><span style="font-weight: bold; font-style: italic;">net.ipv4.tcp_rmem</span> = 4096 87380 16777216
</pre>
</div>
<p>
上面的设置有三个值：最小值、默认值、最在值。
</p>
<p>
请注意，我们在使用window scaling，window size将是动态的，并且持续增长，直到最大值。
</p>
<p>
下面是send window 设置，与上面的receive window设置相似。
</p>
<div class="org-src-container">
<pre class="src src-conf"><span style="font-weight: bold; font-style: italic;">net.ipv4.tcp_wmem</span> = 4096        16384   16777216
</pre>
</div>
<p>
设置完这些之后，我们通过以下命令让其生效：
</p>
<div class="org-src-container">
<pre class="src src-sh"><span style="font-weight: bold; font-style: italic;"># </span><span style="font-weight: bold; font-style: italic;">sysctl -p /etc/sysctl.conf</span>
</pre>
</div>
<p>
另外，通过修改/proc下的文件也能达到目的，
</p>
<div class="org-src-container">
<pre class="src src-sh"><span style="font-weight: bold;">echo</span> <span style="font-style: italic;">'16777216'</span> &gt; /proc/sys/net/core/rmem_max
<span style="font-weight: bold;">echo</span> <span style="font-style: italic;">'16777216'</span> &gt; /proc/sys/net/core/wmem_max
</pre>
</div>
</div>
</div>
</div>
<div class="outline-2" id="outline-container-orgcf2a739">
<h2 id="orgcf2a739">原文，防链接失效</h2>
<div class="outline-text-2" id="text-orgcf2a739">
<p>
Before the Linux kernel version 1.3.57, there was no mechanism other than recompiling the kernel, if you wanted to modify some system parameters.
</p>
<p>
And recompiling the kernel for each and every modification you needed was not at all a good idea. Simply because it didn’t offered flexibility, and it was not possible for a normal day to day user to sit and recompile, a kernel for modifying a value to his required one.
</p>
<p>
Hence there was a need to provide a user interface, using which a user can easily modify kernel parameters, at run time, without recompiling the kernel. Hence Sysctl was introduced. Before the introduction of sysctl in Linux. Almost all kernel parameters, were defined as constants. However using sysctl you can modify these constants to fit to your needs.
</p>
<p>
In this article we will be discussing some of the sysctl parameters, that affects the performance of network. Before getting into the details, let's first see some of the things that can be modified using sysctl.
</p>
<p>
Device parameters
</p>
<p>
Network parameters
</p>
<p>
Firewall behavior
</p>
<p>
File system
</p>
<p>
NFS
</p>
<p>
Processes
</p>
<p>
Version details and much more..
</p>
<p>
A complete list of all sysctl parameters, can be found by running the below command.
</p>
<p>
[root@www kernel]# sysctl -a
</p>
<p>
Discussing all of them is beyond the scope of this article. However in the coming days I will surely write about a few more options available in sysctl. 
</p>
<p>
We will be discussing Network related switches in sysctl, which on modification can result in speeding up network substantially. 
</p>
<p>
Most of the Linux users out there are aware of the fact that, whatever you modify in sysctl, it ultimately modify some file in the /proc directory. On a running system you can redirect your required values to files in /proc file system, which will immediately get applied. However its better to always use sysctl to modify kernel parameters. 
</p>
<p>
The primary objective of this article is to understand these network related options available in sysctl, and what exactly they do, as far as networking and communication is concerned. We will discuss what each of these options one by one, and understand how does they fit into the whole picture of networking in Linux. 
</p>
<p>
Let's understand some basics of networking and TCP before we go ahead and fine tune these parameters on our Linux machine. 
</p>
<ol class="org-ol">
<li>Round Trip Time</li>
</ol>
<p>
This is nothing but the amount of time it takes to send a packet to the receiver and the time took to get an acknowledgement from the receiver.  Hence the round trip time is the amount of time it took to send an IP packet and then receive and acknowledgement from the other side. In networking this can be tested with a very highly used command called PING.
</p>
<p>
C:\Users\sarath&gt;ping slashroot.in
Pinging slashroot.in [212.71.233.103] with 32 bytes of data:
Reply from 212.71.233.103: bytes=32 time=130ms TTL=51
Reply from 212.71.233.103: bytes=32 time=130ms TTL=51
</p>
<p>
The time=130ms (milliseconds), shows the round trip time for reaching slashroot.in, from my computer. My server is located at a Linode datacenter in London. And the time it took for an IP packet to reach my server from my current location of Hyderabad (India), and then get an acknowledgement back from London it took 130 milliseconds. 
</p>
<p>
2.TCP and its connection Type
</p>
<p>
Transmission Control Protocol (TCP) is a connection oriented protocol. Now why is it called as connection oriented?. Its because of a reliable establishment of a connection between the sender and the receiver before any data transmission occurs. This connection establishment is very important, because the sender needs to properly deliver its data to the receiver and then also confirm that the data was delivered properly.
</p>
<p>
Read: How a TCP connection is Established
</p>
<p>
Once a reliable connection is established, then data can flow in both the direction. From sender to receiver and back from receiver to sender. The sender also needs to confirm the proper delivery of the data, by waiting for an acknowledgement from the receiver. Please remember the fact that "Who sends data has nothing to do with who originated the connection".
</p>
<ol class="org-ol">
<li>What are segments, packets, and frames</li>
</ol>
<p>
People use these terms (segments, packets, and frames), interchangeably in networking. However they are totally different. You might already know that in networking there are 5 different layers. The first one is Application layer, Transport layer, Network Layer, Data Link Layer, and the finally comes the Physical layer(This physical layer is the layer where data flows through the wire).
</p>
<p>
Whenever any application sends data to a remote server (For example, you are browsing this web page with your favorite web browser called Mozilla Firefox). While browsing, Application layer is taken care by your web browser and the operating system, and Transport layer is taken care by the TCP suite in your operating system, And network layer is where IP address and receiver address details comes (which is also taken care by the networking stack installed in your operating system), then comes the Data link layer where hardware part is involved like MAC address etc, and then comes the physical layer where the final data is crafted on the wire to be transmitted.
</p>
<p>
Hence whatever you send to the server from your system travels through these different layers (Each layer adds its own bit of information to the data submitted by the previous layer.).
</p>
<p>
Data at Transport Layer is called Segments
Data at Network Layer is called as Packets
Data at the last layer is called as Frames(ready to be transmitted over wire)
</p>
<p>
Now we discussed previously that TCP is a reliable protocol. Its reliable because whatever you send, the receiver must acknowledge that it has got the thing you send. I must say that all the bytes you send must be acknowledged by the receiver. Now what if the receiver does not acknowledge?. If the receiver does not acknowledge, then the sender will resend the bytes those where unacknowledged.
</p>
<p>
It appears to be quite simple when we talk about sending and getting an acknowledgment back. However setting out to implement this in a reliable manner is a quite tough task, and you need to consider a lot of things.
</p>
<p>
Things like how much amount of data will be send on a continues base before the sender gets an acknowledgement back. How much data can the receiver handle before its finally being processed by the receiving application.
</p>
<p>
Those issues related to implementing such a reliable communication protocol is addressed by something called as Flow Control in TCP. Now let's understand what is Flow Control (Don't worry we will configure and fine tune our settings in Linux, once we understand these concepts.)
</p>
<p>
Flow Control in TCP
</p>
<p>
So the problem that will be addressed using Flow control in TCP is the proper amount of data that will be send and received. Data send by the sender must not be large enough to overwhelm the receiver.
</p>
<p>
Now such a control over communication is very much important because we have networks of different speed communicating with each other.
</p>
<p>
TCP uses something called Sliding window Protocol for managing this flow control. Its working is quite simple to understand. Both receiver and the sender will inform each other about the amount of data it can accept. Now the thing is how is this information shared with each other. There is a field in each TCP segment that is send and received called as "receive window" (Please note that we are talking about segments, hence its in the Transport layer). The receiver will mention the amount of data that it can accept or say willing to accept in "receive window" field.
</p>
<p>
The sender on seeing the receive window size mentioned in the the segment sent by the receiver, will make a note of it. Now the sender cannot send more than the receive window size mentioned by the receiver until they are acknowledged. Once the acknowledgement is received, and a new receive window value is send by the receiver, the sender can now send next set of data (again only that amount of data which the receiver has mentioned in the receiver window size.)
</p>
<p>
If a receiver sends a receive window size of 0, the sender cannot send any more data till an acknowledgement is received for its previous sent data and a new receive window size is send by the receiver.
</p>
<p>
The sender cannot send any more data until and unless a new receive window size is send by the receiver.
</p>
<p>
There is always a limitation of what you can include in an IP packet or a TCP segment. The limitation is because of the standard size alloted to each field in a TCP segment, as defined in the protocol specification. TCP is not a very new technology, and was made at the time when networks were really slow compared to the high speed networks we have today.
</p>
<p>
Hence there was a need to modify or say include and modify some additional features as far as performance is concerned. Hence RFC 1323 was born. It contains details about performance improvements in TCP.
</p>
<p>
The limitation was that the maximum receive window size that can be included in a TCP frame is 65,535 bytes. Now that is a very low number, if you take todays network speed into consideration.
</p>
<p>
The new modification came up with something called as window scaling, that increases the limit of receive window size from 65535 bytes to a maximum of 1,073,725,440 bytes (which is very close to 1 Giga byte). To understand this more closely let's dive into a little bit of calculation. This calculation is called as Bandwidth Delay Product.
</p>
<p>
Bandwidth Delay Product
</p>
<p>
The term bandwidth delay product in itself is quite self explanatory. Its the product of Bandwidth and Delay caused while communicating between two end points. Now let's see what's it.
</p>
<p>
The second value with which we will multiply the bandwidth is nothing but the delay caused in sending a packet and then getting an acknowledgement back. We saw how to determine that value in our Round Trip Time section.
</p>
<p>
Now if you have your bandwidth of 10Mbps, and has a RTT (Round Trip Time) of around 200ms for reaching your target receiver, then the Bandwidth delay product will be.
</p>
<p>
Bandwidth Delay Product = 2 x 106  b/s x 200 x 10-3 s =  244.14Kilobytes
</p>
<p>
You can calculate Bandwidth delay product from the link shown below.
</p>
<p>
Calculate Bandwidth Delay Product
</p>
<p>
The bandwidth delay product result shows the amount of bytes that must be transmitted, to efficiently use the connection speed. However as our operating system has this default value of 65535 bytes (65 Kilobytes )window size, the connection is not at all efficiently used.
</p>
<p>
If you calculate 244.14 - 65 = 179 KiloBytes is left unused. So the more Round Trip Time you have the more data needs to be send to fully utilize the link speed(because more delay means you need to send a little bit more data at once, to utilize the bandwidth.). Bandwidth Delay product will go on increasing if the latency (Round Trip Time) is more.
</p>
<p>
Hence to solve this problem we need to use a higher window size. As mentioned before performance improvements were brought to TCP with a new modification in the form of RFC 1323. Increasing the window size for performance is implemented in the form of something called as TCP Window Scaling.
</p>
<p>
Using Window Scaling option in TCP will improve your network throughput and speed, if you have your Bandwidth Delay Product more than 65kilobytes.
</p>
<p>
Let's go ahead and modify our Linux system's TCP parameters, to by default use this option called TCP Window Scaling. As we discussed in the beginning of this article, enabling this option of window scaling is done by modifying sysctl.conf file.
</p>
<p>
net.ipv4.tcp_window_scaling = 1
</p>
<p>
Even after enabling window scaling option, the maximum amount of data that can be send to a receiver without getting an acknowledgement back depends on one more factor. Its called as receive window size. This is the maximum amount of data that a receiver can buffer before being processed by the receiving application.
</p>
<p>
Now if the receiver's receive window size is smaller, even after setting up window scaling option the sender can only send maximum data size equal to the receive window size configured at the receiver end.
</p>
<p>
Hence we need to modify the receive window size to a bigger maximum value. This configuration is also made using sysctl.conf file, with the below option.
</p>
<p>
net.core.rmem_max = 16777216
</p>
<p>
Apart from receive window size, the sender must also have a higher value in the maximum send window size. You might be thinking why there is a requirement of fixed value of send and receive window size. This is because the sender must keep track of the bytes its sending till it gets an acknowledgment back. Because if the acknowledgement doesn't come, then the sender has to resend the entire bytes (if its in buffer it can resend it. Hence this buffer data is not flushed until an acknowledgement comes.)
</p>
<p>
Modifying the maximum send window size, is also similar to the way we modified the maximum receive window size.
</p>
<p>
net.core.wmem_max = 16777216
</p>
<p>
Now other than the above mentioned maximum values of receive window size and send window size, there is one more setting that the operating system uses which sets these values for different conditions. Let's see that option (this is also set in sysctl.conf file). Let's see the receive window size values first.
</p>
<p>
net.ipv4.tcp_rmem = 4096 87380 16777216
</p>
<p>
There are three values in there.
</p>
<p>
The first value is the minimum amount of receive window that will be set to each TCP connection, even if the system is under extreme high pressure.
The default value allocated to each tcp connection
The third one is the maximum that can be allocated to a TCP connection
</p>
<p>
Please don't forget the fact that we are using window scaling option, hence the window size will be dynamic and will go on increasing till the maximum receive window size reaches
</p>
<p>
Similarly there is send window settings, which is shown below. (The three values in send window settings also denote the three things we discussed above)
</p>
<p>
net.ipv4.tcp_wmem = 4096        16384   16777216
</p>
<p>
Hence all these things combined together our sysctl.conf file will look something like the below.
</p>
<p>
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096        16384   16777216
</p>
<p>
Once you have modified your sysctl.conf file with the above required settings, you can reload the configuration and make it permanent, by the below command.
</p>
<p>
sysctl -p /etc/sysctl.conf
</p>
<p>
Alternatively you can also modify the above values on the fly, by redirecting your required values to the required file in /proc. This can be done as shown below.
</p>
<p>
echo '16777216' &gt; /proc/sys/net/core/rmem_max
</p>
<p>
echo '16777216' &gt; /proc/sys/net/core/wmem_max
</p>
<p>
Hope this article was helpful in understanding some concepts behind tuning of TCP in Linux.
</p>
</div>
</div>
</div>
<div class="status" id="postamble">
<p class="author">Author: gdme1320</p>
<p class="validation"><a href="http://validator.w3.org/check?uri=referer">Validate</a></p>
</div>
